fix(providers): support Ollama Cloud execution contracts - #6601

I reviewed all 14 changed files at 945fbdc463e6abc9b36ba9ea03de2581ce59081b (+317/−27), including provider selection, request preparation, direct and captured message encoding, codec identity, and the added Settings/model regressions. I found no confirmed P0–P2 issue in that scope.

The underlying failure is supported by the bundled catalog and executable controls: Ollama Cloud declares includeUsage: true and reasoning replay as reasoning, while the base execution gate rejects that combination. The revised gate accepts it and continues to reject the unimplemented reasoning-details and usage-normalization policies (providers/src/api/route.rs:48–75). The Settings path also explains the missing-choice symptom: model_choice drops models when provider metadata preparation fails (settings/native/src/service.rs:107–118).

The protocol premise has independent support. Ollama documents the cloud endpoint and stream_options.include_usage in its OpenAI compatibility documentation; its request implementation decodes reasoning and transfers it into the internal thinking field. This supports the selected wire field, but does not establish a successful authenticated cloud request.

I traced the selected adapter into the internal maka options, the usage switch in request preparation, and both message encoders. The default codec remains byte-identical, while the non-default reasoning field changes its identity (model/src/adapters/wire.rs:70–86), so the two captured encodings do not alias. No runtime protocol epoch or database schema changes are introduced.

Locally, the unmodified provider-protocol source passed its 20 existing tests in an isolated workspace with the repository's dependency versions. Thirteen additional checks passed using actual extracted gate/options/codec functions and the actual protocol library with controlled surrounding types. These cover catalog rejection/acceptance, explicit usage opt-out, unsupported-policy rejection, Unicode and tool-call replay, invalid field selection, default codec compatibility and absence of internal maka options from the request. Removing only the new reasoning-field remap made the replay check fail; restoring it passed. These are component checks, not a full model or Settings execution.

An actual merge into rust-preview at 74765152efe5e25dc38d6eb947f9b027127aed4c completed without conflicts. Current-head CI has passed tooling, root-build, product, packaging, bridge, native-ubuntu and all 22 root test partitions. I checked the raw logs for all seven added provider/model/Settings regressions, including the local HTTP reasoning/usage cases and the enabled Settings model-choice case: each passed.

The current macOS job has failed after successful compilation. Its desktop suite passes three cases, then desktop_creates_only_on_first_submission_and_preserves_the_confirmed_snapshot fails after 68.383s because the expected selected.png draft is absent (desktop_new_session.rs:265, observed: Null); 18 cases remain unrun due to fail-fast. The current base's macOS log, at the same 74765152 base, records the same case and draft failure after 67.967s, also leaving 18 cases unrun. The test file is identical between base and head. I have not established this PR as the cause of that failure. Windows job 128780933887 is still compiling, so the run has no final result and complete platform acceptance remains unconfirmed. I have not locally run the full model/Settings suites or an authenticated Ollama Cloud session; the HTTP fixture does not establish live cloud behavior.

Automated review notice: This comment was posted by an automated review agent operated by Astro-Han. It is not an independent human review and does not replace one.